昨天聊的是 User Story Mapping 這本書有關於 User Story 的部分，今天就來聊聊有關於 User Story Mapping 這個概念。

在過去透過 Essential Scrum 瞭解的 Product Backlog 一直是一維的形式，也就是一個清單從上列到下，上面的越清晰、精細、下面的越模糊、粗糙，然後隨時按照優先順序去調整，這也就是一般能透過常見的專案管理工具，諸如 Asana、Jira、Trello 能夠呈現的方式。

但是這樣一維的清單式陳列我們的 Product Backlog，雖然有助於我們將他透過 Priority 逐步消化，卻不適合讓我們檢視產品的全貌。這種情況在開發了一段時間，已經進入偶爾加新功能、半維護的產品可能還不是大問題，但是當我們正處於一個還在開發新產品的階段，就很容易迷失，不確定我們產品到底開發到什麼程度。

這也是我當初在前公司時，較難去解決的問題。因為對產品全貌沒有校準，所以在討論上也會容易失焦，每個人都有自己的想法，在 Planning 時也容易針對 Priority 爭辯不下。有時候 Item 也會淪為 Technical Item，較難產出 End-to-End、對客戶或使用者有價值的 Story Item。

而越讀完這本書，我才意識到我少了帶團隊透過 User Story Mapping 建立對產品全貌共同理解的活動。

思考寬度一公里，思考深度一公分。
在迷失於細節之前，先達到使用者故事的尾端。
在 User Story Mapping，基本上我認為是 2.5 維的。在 X 軸，我們依照這個產品被使用的起點去建立起流程，而且在不同階段可能會對應到不同的使用者。所以我們也會把使用者展露出來，並且依此去挖掘他還有什麼功能是必要的。如此我們就可以先針對產品全貌有一個粗糙但全面的暸解，而這就是我們產品的骨幹與骨架。

每個故事一該擁有一個明確關聯的商業價值。
接著我們再把這些在流程上代表功能的項目拆成一個個相關的 User Story，這些都是延伸這個功能的細節，也些可能是必要、有些可能只是想要。於是我們的 Y 軸除了代表細緻化程度（骨幹、骨架的 User Tasks 到細節畫的 User Story）外，也會在 User Story 階層有 Priority 與版本的順序，我們將眾多的 User Story
分為數個里程碑，越前面越是必要的功能，越後面則是加分的功能。

如此一來，我們就有了一個產品的全貌。

雖然在去年讀了這本書，卻一直苦於沒有一個實作的機會。直到今年團隊要針對一個新的產品進行開發，於是我們就在 Kick Off 時進行了這樣的活動。最讓我印象深刻的就是在完成產品的全貌後，團隊因為範疇都被視覺化出來後，感嘆原來要做的事情這麼多外，更多在於團隊依照這個全貌與 PO 一起協商第一個版本的範疇的畫面。我們討論了很久後，終於才有一個定論，也讓我可以再有了產品全貌的情況下，進行產品開發。